System and method for managing electronic interactions based on defined relationships

ABSTRACT

Aspects of the subject disclosure may include, for example, a process that includes receiving first input defining a relationship between first and second entities, generating a first rule based on the first input, wherein the first rule determines accessibility of a networked service, and associating the first rule with the relationship. The first rule modifies settings of a service management infrastructure to effectuate the first rule in accordance with the relationship, wherein the service management infrastructure provides access to the networked service based on the accessibility. Other embodiments are disclosed.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/237,966, filed Jan. 2, 2019, which is a continuation of U.S.application Ser. No. 14/645,454, filed Mar. 12, 2015 (now U.S. Pat. No.10,187,388), which are incorporated herein by reference in theirentirety.

FIELD OF THE DISCLOSURE

The subject disclosure relates to a system and method for managingelectronic interactions based on defined relationships.

BACKGROUND

Communications services support exchanges of information among variousentities and according to various modes, such as voice, video, textmessages, and more generally through access to data, softwareapplications, and even computing resources themselves. Likewise, cloudservices provide entities with access to various resources that can alsosupport the processing and exchange of information. Those in thebusiness of providing such services are in a privileged position to helpmanage and execute electronic or digital interactions that allow suchaccess to resources and information exchanges.

Current approaches to managing electronic interactions can invokenetwork behaviors. The network behaviors include, without limitation,one or more of connectivity, data store, and software applications, andare generally very specific, e.g., responding to a particular request.In some instances, such network behavior can be common across partiesengaging a common network capability. The behavior, however, is tied toa specific request, as in a routing of a voice call based on areachability status of the call recipient. Calls from specificindividuals, such as family members, may be routed to the recipient,while calls from other parties are directed to a voice mailbox, orblocked altogether. The call recipient may unilaterally identify thespecific individuals to the network service provider to allow forspecial call routing.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIGS. 1-3 depict illustrative embodiments of a relationship managementsystem;

FIG. 4 depicts an illustrative embodiment of a graphical representationof entity relationships;

FIG. 5 depicts an illustrative embodiment of a relationship managementsystem;

FIGS. 6A, 6B, and 7-8 depicts illustrative embodiments of methods usedin portions of the system described in FIGS. 1-3 and 5;

FIG. 9 depicts an illustrative embodiments of a communication systemthat provides services according to managed relationships as describedin FIGS. 1-8;

FIG. 10 depicts an illustrative embodiment of a web portal forinteracting with the relationship management systems of FIGS. 1-3 and 5,and the communication system of FIG. 9;

FIG. 11 depicts an illustrative embodiment of a communication device;and

FIG. 12 is a diagrammatic representation of a machine in the form of acomputer system within which a set of instructions, when executed, maycause the machine to perform any one or more of the methods describedherein.

DETAILED DESCRIPTION

It is recognized that various social relations exist between entities orparties that engage in such interactions. The subject disclosuredescribes, among other things, illustrative embodiments for managingelectronic interactions, such as accessing networked services, based ona pre-defined and mutually agreed relationship between entities. Forexample, in a cloud based/virtual environment, a first party can definerelationships with one or more second parties. The relationship candetermine rules that affect or otherwise control a behavior of theinteractions, such as network and cloud based application behavior.

Other embodiments are described in the subject disclosure.

One or more aspects of the subject disclosure include facilitatingaccess to a managed service according to a predefined behavior that isbased on a mutually agreed relationship between different entities. Theaccess can be according to any of various modes, such as dataaccess/exchanges, communications including reachability, applications,computational resources, machines, avatars, and the like. A serviceprovider, such as a network service provider, a cloud service provider,an application service provider, a storage service provider, and thelike, facilitates affects or otherwise modulates a behavior of theaccess to the service according to rules and/or policies of thepredefined relationship. In particular, the predefined relationship isimposed upon the transaction when the involved entities have mutuallyagreed to a behavior (roles/rules/policies) of the relationship. Thiscan include mutual assent to any modifications to the behavior. Therelationship, indicia of the entities, related roles, rules and/orpolicies, including modifications can be stored in a database that isaccessible by a relationship managing entity.

One embodiment of the subject disclosure includes a process thatincludes providing, by a system comprising a processor, informationrelated to selectable rules to equipment of a first party and equipmentof a second party, wherein the selectable rules define a relationshipbetween the first party and the second party. A first rule is generatedaccording to first selections received from the equipment of the firstparty and second selections received from the equipment of the secondparty. The first rule is associated with the relationship between thefirst party and the second party, wherein the first rule modifiessettings of a network element to effectuate the first rule in accordancewith the relationship between the first party and the second party,wherein the network element provides a network-accessible service, andwherein the settings modified by the first rule restrict dataaccessibility of the network-accessible service. The first rule isstored in association with the relationship between the first party andthe second party.

Another embodiment of the subject disclosure includes a device having amemory that stores executable instructions and a processor coupled tothe memory. The processor, responsive to executing the executableinstructions, performs operations including receiving preferences fromequipment of a first party, equipment of a second party or both, whereinthe preferences define a relationship between the first party and thesecond party. A first rule is generated based on the preferences, andthe first rule is associated with the relationship between the firstparty and the second party. The first rule modifies settings of aservice infrastructure to effectuate the first rule in accordance withthe relationship between the first party and the second party. Theservice infrastructure provides a network-accessible service and thesettings modified by the first rule restrict data accessibility of thenetwork-accessible service. The first rule is stored in association withthe relationship between the first party and the second party.

Yet another embodiment of the subject disclosure includes amachine-readable storage medium, including a number of executableinstructions that when executed by a processor, cause the processor toperform operations. The operations include receiving from equipment of afirst entity, equipment of a second entity or both, first input defininga relationship between the first entity and the second entity. A firstrule is generated based on the first input, wherein the first ruledetermines accessibility of a networked service. The first rule isassociated with the relationship between the first entity and the secondentity. The first rule modifies settings of a service managementinfrastructure to effectuate the first rule in accordance with therelationship between the first entity and the second entity and theservice management infrastructure provides access to the networkedservice based on the accessibility.

FIG. 1 depicts an illustrative embodiment of a relationship managementsystem 100. The system 100 includes a relationship manager 104, whichcan be used to control or otherwise tailor various modes of electronicand/or digital interaction of one or more entities 102 a, 102 b,generally 102. The modes of interaction can include, without limitation,access to network-accessible services, such as data sharing, e.g.,automated information transfer, read, write, automated notifications,reach services, application access/functionality, processing resourceconfiguration and/or availability, contract related services, and thelike.

The relationship manager 104 is in communication with equipment of oneor more of the entities 102, and in further communication with one ormore other systems and/or services, such as storage systems 110 a,application software and/or application services 110 b, processingresources 110 c, and network devices and/or services 110 d, such astelecommunication network, a computer network, a mobile network, andmore generally anything that stores, processes, and/or reacts tometadata about the actions of the entities 102, and the like. Theseresources or services can be referred to, generally, as informationresources 110. The equipment of the entities 102 can include, withoutlimitation, communications equipment, such as telephones, smart phones,pagers, VoIP terminals, computers, tablet processors, vehicles,machines, robots, and more generally anything with communicationcapabilities and/or a modifiable behavior. For example, implantablemedical or recreational devices, cloud based services (private and/orpublic cloud), and the like.

The storage system 110 a can include local storage including one or moreof memories, hard disc drives, optical storage drives, flash storagedevices and the like as might be within the possession of one or more ofthe entities 102 or a third party. Alternatively or in addition, thestorage system 110 can include remotely accessible storage, such asnetwork storage. By way of example, such remotely accessible storage caninclude network storage resources, e.g., storage provisioned orotherwise offered by an enterprise, such as an employer, an educationalinstitution, and the like. Remotely accessible storage can also includecloud storage solutions, such as those provided by Apple Inc's iCloud®information management service, Google Inc.'s Google Drive, and backupstorage solutions, such as Carbonite Inc.'s Carbonite® backup servicesand products. (iCloud® and Carbonite® are trademarks registered by theApple Inc. and Carbonite Inc., respectively).

The applications software 110 b includes one or more of softwareresident on equipment of one or more of the entities 102, softwareprovided by an enterprise, such as an employer of one of the entities102, a third party, such as a service provider, and the like. Thesoftware can be provided as executable programs resident on equipment ofthe entities 102, or provided by another source, such as an applicationserver, an application service provider, etc. Applications can be ownedby the entity or owned by hosting service provider. The application canbe executed on the entity equipment or the hosting service provider.

The interactions can include interactions between the entities, i.e.,between equipment of each of the entities, or equipment in use by or foreach of the entities 102. Alternatively or in addition, the interactionscan include interactions of either or both entities with variousservices, applications, processing resources, e.g., informationresources 110, and in some instances with other entities not necessarilysubject to the relationship. The interactions, regardless of the variousmodes and/or equipment, are based on a predetermined relationshipbetween the entities 102. That is, interactions between equipment of theentities 102 and/or between the entities 102 and other informationresources 110 are subject to roles, rules, and/or policies establishedby the predetermined relationship between the entities 102. For purposesof illustration, a relationship between the entities 102 is illustratedas a dashed line 103.

In more detail, the example relationship manager 104 includes a behaviormodule or engine 108 and an access manager 106. The relationship manager104, e.g., by way of the behavior engine 108, is in furthercommunication with one more of the other information resources 110. Inoperation, the behavior engine 108 associates one or more roles, rules,policies, as behavioral attributes to the relationship between theentities 102. The behavioral attributes can be applied to electronic ordigital interactions of the entities 102 to control one or more aspectsof the interactions with the information resources 110. Interactions caninclude identity services, relational services, computational services,communication services, data services, security and privacy services,among others.

In some embodiments, access to one or more of the information resources110 or services can be managed according to a service managementinfrastructure. Managed access can include selectively allowing,blocking or otherwise modulating access to the service. In someembodiments, managed access can include provisioning new services and/ormodifications to existing services. Managed access can also includeconfiguring attributes of the service, such as authorization for access,modification, and so forth. Such infrastructures can include acontroller, such as a network and/or data storage controller, a gatewayserver, a scheduling server, software, such as a medical records system,and the like.

The access manager 106 selectively provides or otherwise allows accessto one or more features of the managed relationship. The access module106 can provide one or more sub-modules, such as an authenticationmodule 122, an authorization module 124, and/or a registration module126. By way of non-limiting example, an authentication module 122 canprovide any of a number of authentication techniques. That is, one ormore of the entities can be authenticated by the authentication module122. Authentication can include, separately, or in some combination, apassword, a digital value, such as a token and/or a digital signature.Alternatively or in addition, authentication can be based on biometricattributes, such as a fingerprint, a retinal scan, a voice signature, afacial image, and the like. Still other authentication techniques caninclude equipment identifiers, e.g., SIM card of a mobile phone or aproduct or equipment ID number. Alternatively or in addition,authentication can leverage other factors, such as a date, time,location of the authenticating party, a telephone number and so on. Anyof the various authentication techniques can be used alone or combinedin a multifactor authentication. For example, a selection of whichauthenticating factor or combinations of factors are used forauthentication can be determined dynamically, e.g., to compensate forcontextual risks, such as threat levels, unusual circumstances, failureof some factors and so forth. Authentication provides some measure ofassurance that the authenticated entity or persona is who he/she/itpurports to be, at least to a reasonable degree of certainty.

Identity services can include, for example, creating, updating and/orremoving of personas—personas include identities associated with anentity. In general, an entity relates to a real or physical entity, suchas a person, an organization, a machine. An entity can also relate to anintangible entity, such as an online presence, as in an avatar, avirtual machine, an online group, and the like. Although relationshipsare loosely described as being between entities, it should be understoodthat the relationships can also exist between one or more personas ofone entity with another entity and/or with personas of the other entity.Different personas allow the same entity to differentiate itself as maybe beneficial in the context of relationships.

The authorization module 124 can be used to provide a separateauthorization to access features of the managed relationship and/orservices affected by the managed relationships. Authorization can bebased on results of authentication alone or in combination with otherinformation. Authorization, in at least some instances, can relate to apermission having been granted, e.g., by a service provider, one of theentities 102, and/or another entity or organization. Such permission mayresult from a subscription, e.g., to services of a network and/or cloudservice provider, or to another entity, such as an application manager.Other information used in connection with authorization can include anyof the authenticating factors discussed herein alone or in combination,including identities, machine or equipment IDs, times, dates, locations,occurrence of events, and so forth.

The subscription module 126 optionally provides yet another layer ofaccess to resources and services. This may include verification that anentity or party to a relationship has subscribed or otherwise registeredto a resource/service of the relationship manager 104, such as access tomanaged relationships, definition, modification, deletion, and so forthof one or more of relationships, entities, rules, policies and the like.The subscription module 126 can also coordinate, establish or otherwiseidentify other business processes and/or systems. For example, asubscription can include processes related to establishing and/ordetermining eligibility, accounting and/or billing. Still otherprocesses can include extending offers, directing advertisements, etc.

The access manager 106 implementing an access management function is incommunication with each of the parties 102. A timing of thecommunications with the access module 106 may vary depending on theaction undertaken by the entities 102. For example, if the first party102 a is defining or modifying a relationship, then the first party 102a is in communication with the relationship manager 104. The secondparty 102 b does not necessarily have to be in communication with therelationship manager 104 at the same time. However, at some point, thesecond party 102 b may access the relationship manager 104 to review aproposed relationship, including its associated roles, rules and/orpolicies, and to assent to or otherwise approve the relationship and itsbehavior.

FIG. 2 depicts an illustrative embodiment of another relationshipmanagement system 200. A user device 202, e.g., a smart phone, is usedto implement interactions that are linked to or otherwise associatedwith managed relationship behaviors. The system 200 also includes arelation manager 204, shown resident within architecture of a serviceprovider system 206. The service provider system 206 supports userinteractions with one or more information resources, such as vehicularinformation systems 210 a, personal information systems, such aswearable information systems 210 b, e.g., Google Glass, desktop and/ortablet processors 210 c, smart phones 210 d and the like, referred togenerally as information systems 210. The information systems 210 caninclude equipment of the entities, such as the user device 202,resources and services of the service provider, and/or resources andservices of another party or organization.

The system 200 includes an access manager 207 implementing an accessmanagement function, shown as separate from the service provider system206. It is understood that one or more of the modules, such as therelation manager 204, the access manager 207, or the information systems210 can be included within a common architecture of the service providersystem 206, or separate from the service provider system 206. Forexample, one or more of the relation manager 204 or the access manager207 can be provided and otherwise controlled or managed by an entitydistinguishable from the service provider system 206. Consider theservice provider acquiring access to the services of such modules on acontract basis, offering the services to their customers as part of abundle of subscribed services.

In connection with one or more of identity and relationship management,the user equipment 202 can provider identification functionality. In theillustrative example, identity functionality 205, e.g., an applicationor app is launched from the smart phone 202. The identity app 205 maypresent a user with a selection from among a number of differentidentities. These can be different entities, or personas, of the sameentity or individual. It is understood that the identifier functionality205 can be tied to an authentication and/or log-in process that allowidentities/personas to be managed without regard to the underlyingequipment, e.g., the mobile phone 202. Here, the identifierfunctionality shows two different personas associated with the user. Afirst persona relates to a work-related persona, e.g., a work ID 207 a.A second personal relates to a family-related persona, e.g., a family ID207 b. The device 202 may include a separate device identifier 209,e.g., according to a SIM module of the smart phone 202.

In operation, a user 201, after launching the identifier functionality205, selects one of the personas, e.g., the family ID 207 a. Theselected family ID 207 a, optionally along with other information, suchas user log-in credentials, is forwarded to the access manager 206. Theaccess manager 206 can include one or more of an authentication module222, an authorization module 224 and a subscription module 226. Each ofthe modules, in turn, can authenticate, authorize the user and/or theparticular persona 207 a of the user. Presuming that the authorized userhas subscribed to a service, the subscription module 226 can manageaspects of the subscribed services, including monitoring usage andrelated billing. An accounting module 228 is shown in communication withthe subscription module 226 to provide such features. 202 device on . .. 209 device registers with service provider . . . user 201 invokes 205. . . User Identification with “Authentication” 222 . . . User selectsIdentifier Persona 207 and 224 and 226 . . . subscribed use launchinvoked to 207 and 207 b

Information from the access manager 206 and/or from the smart phone 202are provided to the relation manager 204. The relation manager 204, inturn, supports establishment of new relationships with other entities,as well as management and/or modifications of existing relationships andremoval or termination of relationships, as may be required. Therelationship manager 204 can store or otherwise accesses storedrelationship data, e.g., from a relationship database 211. The storedrelationships can include one or more of indicia of the entities and/orparticular personas of the relationship, a relationship type indicator,and one or more roles, rules and/or policies associated with therelationship. The roles, rules and/or policies apply to interactions ofthe user, e.g., by way of the user device 202. It is contemplated thatthe stored relationship as determined by the entities may includepointers or other suitable reference to roles, rules and/or policiesthat are defined elsewhere. In some embodiments, the relationship recordor data structure can include other fields, such as an in-scopeindicator, e.g., a particular application, data file, informationresource to which the pre-defined relationship applies.

FIG. 3 depicts an illustrative embodiment of yet another relationshipmanagement system 300. The relationship management system 300 includes apolicy and/or rules framework architecture 304 that supports multiplephases of establishing accounts, configuring or otherwise managingservices associated with the accounts, and using or otherwiseimplementing the services. The framework architecture can include aproduct information system or module 306, a subscription system ormodule 314, a service information system or module 312, and a resourceinformation system or module 316. A user, such as a customer orsubscriber to a service, can access the framework architecture by way ofuser equipment 302. The user can interact with the frameworkarchitecture in various capacities, e.g., establishing or managing anaccount, related configurations and use. The policy and Rules Frameworkdrive the behavior the user 302 experiences in each of these layers ofthe system architecture.

By way of illustration, a user or subscriber account can be establishedby an account ordering system 308. The account ordering system 308 caninclude or otherwise access other business support systems 310, such asbusiness support system (BSS) application programming interfaces (APIs),customer experience, sales, ordering, and billing. The BSS APIs can beused to access or otherwise interact with the product information module306. The product information module 306, in turn, can include one ormore of content, processes, and policies as may be useful inestablishing and managing user accounts.

A subscribed service can be configured by a service configuration system320. The service configuration system 320 can include or otherwiseaccess other service configuration support systems 322, such as relatedAPIs, service configuration, and user rule management. The APIs can beused to access or otherwise interact with the service information module312. Likewise, a subscribed service can be accessed or otherwise used bya user service system 324.

The user service system 324 can include or otherwise access other userservice support systems 326, such as service APIs, storage,computational, network and/or applications management. The APIs can beused to access or otherwise interact with the service information module312. The service information module 312, in turn, can include one ormore of content processes and policies as may be useful in configuringand/or implementing or otherwise using managed relationships. Theframework architecture 304 can also include a resource informationmodule 316, e.g., in communication with the service information module312. The resource information module 316 can include resources that maybe required to support configuration and/or use of services.

The framework architecture 304 can include a subscription module 314that is in communication between the product information module 306 andthe service information module 312. The subscription module 314 canallow for an exchange of information, as may be required inestablishing, managing, and disseminating related services under theframework architecture 304. For example, in response to a request toconfigure services, the service information module 312 may accessinformation from the product information model, and modulate orotherwise provide support and/or limitations to the configured servicesas may result from a particular subscription. Alternatively or inaddition, a request for a particular configuration or use that is notprovided under a particular subscribed service may result in an exchangeof information from the service information module 312 to the productinformation module 306. The product information module 306, in turn, mayoffer the user with an option to acquire the particular configuration oruse under a new and/or modified subscription.

One or more of the account ordering system 308, the serviceconfiguration system 320 and the user service system 324 can be providedin the form of an application, e.g., a client-server application, inwhich a client portion is downloaded to or otherwise resident on theuser equipment 302. Alternatively or in addition, these systems 308,320, 324 can be provided in the form of a stand-alone device, such as akiosk terminal or some other dedicated business terminal, or a webapplication in which user interactions are managed through a browserapplication resident on the user equipment 302. It is understood thatthe architecture of the illustrative relationship manager 300 can becombined or otherwise used in association with any of the otherrelationship management systems 100, 200, 500, 900 disclosed herein.

Referring again to FIG. 1, and with respect to predetermined rules thathave been agreed to by both parties, 102, it is conceivable thatbehaviors according to the rules/roles/policies can be imposed orotherwise applied to interactions of either party 102, both parties,another party outside of the relationship, or any combination thereof.Accordingly, a rule between the two parties 102 can be applied to aninteraction of a third party associated with the relationship 103between the parties 102, without requiring either party 102 to be incommunication with the relationship manager 104 at the time of theinteraction. Namely, the relationship manager can control behavior of aninteraction according to a stored record of the rule, the parties 102,and their mutual assent to the same.

In an illustrative example involving an interaction between the twoparties, each party interacts with the relationship manager at 1 a, 1 bto establish authentication, authorization and linkage to a registeredbehavior by way of the behavior engine 108. A first reach identifierinstance 120 a is established at 2 a allowing the first party to accessa linked relationship behavior by way of the reach identifier instance120 a, without requiring authentication, authorization and/or linkage tothe underlying equipment of the first party 102 a, e.g., the firstparty's smart phone. Likewise, a second reach identifier instance 120 bis established at 2 b allowing the second party to access the likedrelationship behavior. The linked relationship behavior is applied tointeractions at 3 a, 3 b, between the first and second reach identifierinstances 120 a, 120 b. Instead of being assigned to a particularnetwork/telephone/communication switch line or a SIM chip, the reachmanager instances can be registered from any device from which a user,i.e., the entity, can be authenticated. The linked relationship behaviorcan be applied to interactions between the entities 102 directly orindirectly through one or more of the linked services 110. Theinteractions between the parties are illustrated by the arrows at 4.

Accordingly, two or more parties, petitioning for, or allowing, someform of interface (connection, data or other programmatic interface) togate acceptance and follow-on behavior based on a specific set ofattributes, rules and policies. The system 100 allows a relationship totake place where individual, user defined attributes are provided oneach end of the relationship. Namely, the relationship manager 104controls a behavioral interface that can be used to vastly expandentity, e.g., customer, security and control. The two parties 102 a, 102b each authenticate, become authorized and attach to registeredbehaviors by way of the relationship manager 104.

Parties 102 can expose or otherwise provide attributes for considerationin access management and/or in relationship management. The attributescan be provided explicitly by the entities, e.g., as inputs during anauthentication process. Alternatively or in addition, the attributes canbe identified, e.g., in a data structure, or other personal profile.Examples of attributes include, without limitation, static attributes,such as a name, a telephone number, a mobile phone number, a messagingidentification/address, social security number, employee number/ID,membership number/ID, username and/or password. It is understood thatattributes can also include dynamic attributes subject to change.Examples of dynamic attributes include, without limitation, a location,a business group ID, a personal group ID, hardware type and/or hardwareID, date, time, other environmental attributes. The attributes can beused alone or in combination, e.g., applying Boolean logic, to gate orotherwise modify behavior, e.g., according to the predefinedrelationship.

In the illustrative example, a relationship manager instance of thefirst entity 120 a exposes three fixed attributes, e.g., FA1, FA3, FA4of the first party 102 a according to a role/rule/policy of therelationship. Likewise, a relationship manager instance of the secondparty 120 b exposes three fixed attributes, FA5, FA6, FA7 of the secondparty 102 b according to a role/rule/policy of the relationship. Thefirst party 102 a, through its reach identifier instance 120 a and therelationship manager 104, requests connection to the second party 102 bpassing the appropriate attributes FA1, FA3, FA4 according to thepolicy/rule. The second party 102 b, through its reach manager instance120 b and the relationship manager 104, receives the connection requestfrom the first party's relationship manager instance 120 a. One of therelationship manager 104, the reach manager instance of the second party120 b or both validates the attributes attached to the request, andacknowledges the request, passing identifying attributes “FA5, FA6, FA7”to the reach manager instance of the first entity 120 a. One of therelationship manager 104 a, the reach manager instance of the firstparty 120 a, or both validates the returned attributes and the reachmanager instances of both entities 120 a, 120 b invoke a registerednetwork connection behavior.

Although interactions managed according to relationships between twoentities 102 are illustrated, it is conceivable that the relationshipscan include more than two parties. For example, the relationship can befrom one to many, as in the first party 102 a, to a number of otherentities, e.g., as members of a group or organization. The relationshipcan also be among three or more parties, requiring mutual assent of allparties to the relationship. Likewise, the first or second entity canengage in other managed relations to other parties, now shown.

The relationship manager can allow or disallow behaviors among all ofthe “members” in a “group” in a flat (e.g., all rules apply to everyone)and/or in a tiered fashion. For example, ten members of a group joinunder a relationship management controlled process in an interactiveaudio and video conference. Each member of the group is authenticatedand associated with an authorization. In some embodiments, more than oneauthorization can be provided to members of the group, e.g., level 1 andlevel 2. Consider that during the conference, material restricted tolevel 2 authorization needs to be presented. The conference behavior canbe established by a rule(s) to disable the audio and video for level 1participants for the duration of that discussion, returning when thatpart of the conference concludes. Such features can be implementedmanually or automatically based on the particular relationship managerrules and attributes attached to the data being presented

FIG. 4 depicts an illustrative embodiment of a graphical representationof entity relationships. A first graph represents a tree 402 a having anumber of nodes 401 interconnected to one or more other nodes bybranches 403. The tree 402 a can represent multiple identities orpersonas associated with a particular entity. Each node can represent adifferent persona of an entity, such as an individual, an organization,a group, a machine, an avatar, and the like. The tree 402 a can includea root or trunk node 404 a, that might represent a real identity of theentity. This might include, as indicia of the individual, one or more ofa name, a number, an address, a digital value, a picture, an audiosample indicative of the entity 404 a. The entity 404 a can have one ormore additional nodes 401 representing different identities, sometimesreferred to as personas. For example, a person may have a root identityor node 404 a, as in the person's name or personal identificationnumber, such as a social security number. The same person may have otheridentities as in a family member, e.g., a parent, a sibling, a spouse,an employee, e.g., a co-worker, a group manager, a group member. Each ofthe other identity nodes, e.g., family member, employee, are related tothe same root node 404 a as shown by the interconnecting branches.

A second tree 402 b indicative of identities of another entity is alsoillustrated in juxtaposition to the first tree 402 a. The second tree402 b also has a root node 404 b and a number of other nodesinterconnected by branches. The two graphs 402 a, 402 b areinterconnected at one or more nodes by dashed lines 410, 412, 414,sometimes referred to as edges. The edges graphically representrelationships between particular pairs of nodes of the two trees 402 a,402 b. For example, a first edge 410 interconnects a first node 406 ofthe first tree 402 a to a second node 408 of the second tree 402 b. Thefirst edge 410 represents a relationship between a first persona 406 ofthe first entity 404 a and a second persona 408 of the second entity408.

By way of example, according to a workplace paradigm, the first tree 402a can represent a tree of a first individual, e.g., Steve, who happensto be an employee, e.g., a junior engineer (node 406), at Corporation X.The second tree can represent a tree of a second individual, e.g.,Lynda, who happens to be an engineering group manager (node 408) atCorporation X. The relationship 410 between Steve and Lynda can becharacterized as an employee-manager or employee-employer typerelationship. As disclosed herein, one or more rules and/or policies canbe associated with the relationship 410 to affect a behavior ofinteractions of Steve, Lynda, or both in association to therelationship.

Continuing with the employee-employer relationship, interactions caninclude data access and/or exchange. For example, a rule may allow Lyndaas manager to enter data into Steve's employee record. Data mightinclude commendations, training, reviews, etc. Steve and/or Lynda may beallowed to read but not write to all fields of an electronic employeerecord. For example, Steve may be allowed to enter information relatedto training in his own employee record but not information related tocommendations or reviews. Likewise, Lynda, as manager, may be able toenter information in any of the fields of Steve's employee record.

The employee-employer relationship can be established, e.g., at the timeSteve is hired, promoted, and/or changes groups. In establishing orrevising their relationship, Steve and Lynda would review the variousrules, such as those concerning data access, and if they agreed, assentto them. A record of the relationship, the entities and/or personas, andthe rules would then be stored as a record in a relationship managementdatabase. Indicia that each party agreed or otherwise assented to theparticular rules of the relationship can be retained in the same record,or in a related record. Such indicia of consent can contain variousdetails, such as the assenting party, the date, the time, indicia ofauthentication of the assenting party and so forth. Assent to particularrules of the relationship can be tracked independently to provide arecord of when and who assented to particular aspects of therelationship, mutual assent being determined only when both parties haveassented to the relationship in its entirety (this can be determined byoverall assent, or by incremental assent).

It is conceivable that the employee-employer relationship can be betweenthe employee, Steve, and the business entity, Corp. X. Similar rules canbe defined and applied to electronic interactions of Steve, Corp. X, orby another party, such as Lynda as manager, according to therelationship between Steve and Corp. X. In this instance, assent betweenSteve and Corp. X can control a behavior, such as data access to Steve'semployee records, by a third party, Lynda.

Assent can be obtained independent from each party to the relationship,with mutual assent being established or otherwise concluded when allparties have assented. In some embodiments, an assent process includes anegotiation. For example, a proposal identifying a relationship and/orrules is presented. The proposal can be presented from one party toanother, to each party individually, or to all parties collectively,e.g., from an outside entity, such as a relationship broker or manager.

The parties can assent to or otherwise agree to or accept the proposalor, in some embodiments, propose a counter offer. The counter offer canbe a modification or substitute in whole or in part to the proposedrelationship and/or rules. In some embodiments, such proposals aremonitored, e.g., by an outside entity, such as the relationship brokeror manager, for consistency, compliance, completeness, etc. Anyinconsistencies can be identified to allow the proposer of the counteroffer to correct and/or amend the counter offer until compliant. Theparties can assent to or otherwise agree to the new/modifiedrelationship and/or rule, or engage in further modification. In someembodiments, the modifications can be bidirectional, in which each partymay offer modifications until a mutually agreeable relationship and/orrule is identified.

In some embodiments, a proposed relationship and/or rule is presentedwith limited opportunities for modifications. For example, the proposalcan be made as a “take it or leave it” proposition. Such unilateralproposals can be efficient under certain circumstances, e.g., in adoctor-patient relationship in which a doctor's practice proposes a setof rules, e.g., allowing a patient to access medical records. The doctoris generally interested in preserving integrity of and in some instancesaccess to such records. Accordingly, the doctor may not allow thepatient to write to the record, or certain fields of the record, toshare the record without restriction, and so forth. Accordingly, thepatient can merely choose to accept or decline an offer to establishsuch a relationship according to the techniques disclosed herein.

It is also worth noting that in some instances, a direction of therelationship, e.g., from employee to employer may differ from arelationship between the same two entities in a different direction,e.g., employer to employee. Continuing with the example, Lynda may haveauthority to view certain fields of Steve's employee record, such as hissalary. To the contrary, Steve may not be granted authority to viewcertain fields of Lynda's employee record, such as her salary. It isunderstood that such bi-directionality of a relationship can besymmetrical, e.g., the same rule applies to each entity of therelationship in either direction, or asymmetrical, e.g., at least somerules differ depending upon a perspective of the parties to theinteraction (Steve to Lynda, or Lynda to Steve).

As for managing such relationships, it is conceivable that a commonrelationship between parties can be defined according to the same set ofrules applied to either party, or to different sets of rules applied torespective parties of the same relationship. Alternatively or inaddition, relationships between the same parties can be distinguished asdifferent relationships depending upon a perspective of the entities.Namely, the employee-employer relationship between Steve and Lynda canbe managed, e.g., stored, as an entirely separate relationship from theemployer-employee relationship between the same entities, Lynda andSteve.

It should be understood that more than one relationship can existbetween the same two entities, as indicated by the multiple edges 410,412, 414 shown in FIG. 4. Consider a scenario in which the employer andemployee may members of a common advisory board, or some other socialorganization, such as a club or a team. Relationships between the sameentities, e.g., Steve and Lynda can be managed or otherwisedistinguished according to the particular identities or personasassociated with the relationship. Namely, any relationships managedbetween Steve and Lynda as employee-employer can be managed in a linkedmanner, or entirely distinguishably from another relationship betweenSteve and Lynda as co-board members, or co-team members.

As is indicated by the connected nodes and branches of the example trees402 a, 402 b, generally 402, one or more of the identities or personas,the rules or both can have a hierarchal relationship with respect toother identities, personas and/or rules. That is, a particular personaand/or rule may inherit certain attributes and/or rules or policies fromanother personal and/or rule, based on a hierarchal relationship betweenthe nodes and/or edges. Consider the employee-employer relationship 410having rules, such as the aforementioned rules governing dataaccess/exchange. Steve and Lynda as members of a common corporate group,such as a minority employee group, may have a distinguishable secondrelationship as equals. Accordingly, some rules attributed to the firstrelationship may apply to some interactions, whereas other rulesattributed to the second relationship may apply to other interactions.Some of the rules may be inherited, such as reachability under theemployee-employer may apply equally to the minority group members,whereas other rules may differ.

FIG. 5 depicts an illustrative embodiment of yet another relationshipmanagement system 500. The relationship management system 500 includesan access manager 506 to manage access of a first entity 502 a and asecond entity 502 b to a service. In the illustrative example, theentities 502 a, 502 b, generally 502, access a customer experience rulesengine 508. The customer experience rules engine 508 is connected to anetwork 532, such as local area network, an enterprise network, and/or awide area network, such as the Internet. The customer experience rulesengine 508 is in further communication with other resources, such asstorage 510 and/or computational resources 514 by way of the network532. The system 500 can include other modules, such as a customeraccount module 534. It is understood the customer account module 534 caninclude a profile that can be managed or otherwise configured accordingto the entities 502. Namely, an individual user 502 and/or a serviceprovider can establish and otherwise maintain a customer account and/oruser profile by way of the customer account module 534. The customerexperience rules engine 508 can access information from the customeraccount module 534 as may be relevant in accessing and/or managing rulesrelated to the customer experience.

In the context of a relationship manager, the customer experience rulescan implement a relationship management feature in which relationshipsbetween entities 502 can be identified, modified and retained. Use,e.g., access to network services, cloud services, application services,computational and/or storage services and the like can be managed orotherwise gated according to the relationship. As illustrated, thecustomer experience rules engine 508 can manage a customer experience ofthe entities 502 from an edge node of the network 532. The illustrativeaccess manager 506 provides a layered or tiered access by which eachentity 502 can separately be authenticated by an authentication module522, authorized by an authorization module 524 and access subscribedservices through a subscription module 526. Usage or access to any ofthe managed resources and/or services can be blocked or otherwiserestricted when either entity 502 fails to successfully complete themulti-tiered access. It is understood that the architecture of theillustrative relationship manager 500 can be combined or otherwise usedin association with any of the other relationship management systems100, 200, 300, 900 disclosed herein.

FIG. 6A depicts an illustrative embodiment of a process 600 used by therelationship management systems of FIGS. 1-3 and 5. In particular, theprocess 600 relates to implementing electronic or digital interactionsof one or more parties according to a predetermined relationship. Theinteractions can be in the form of accessing a service. The service caninclude access to an application, a system, such as a network, and/or adevice, such as a server, machine, a virtual machine. A request foraccess to a service associated with two entities is determined at 602.Such a request can be determined, e.g., by a communication, such as acall or message from one party to another. Such a request can also bedetermined by a request to access a particular service or system. Theentities are identified at 604. The entities can be identified by anysuitable technique, such as a call or message source ID and/or a call ormessage destination ID. A determination is made at 606 whether arelationship exists between the two entities. This can be accomplished,e.g., by searching a data store of predetermined relations, e.g.,according to one or more of the parties, or requested service orresource. To the extent a relationship does not exist, variousprocessing can take place at 608, for example, denying access to therequested interaction, denying access to a modification of the requestedinteraction according to a behavior of a predetermined relationship, orboth. Such denials can result in a message to one or more of the partiesto the relationship notifying them that a request was made and that therequest was denied. In some embodiments, a denial can result in an offerfor the parties to engage in and/or modify a relationship according tothe techniques disclosed herein.

To the extent that a relationship does exist, the relationship betweenthe entities is identified at 614. In some embodiments, a determinationis made at 610 as to whether one or both of the entities and/or therelationship itself is authenticated or otherwise authorized. Inresponse to a lack of authentication and/or authorization, variousprocessing can take place at 612, for example, denying access to therequested interaction, denying access to a modification of the requestedinteraction according to a behavior of a predetermined relationship, orboth.

Once the relationship has been identified, any roles, rules and/orpolicies associated with the relationship are determined at 616. Adetermination is made at 618 as to whether the predeterminedrelationship, including any associated roles, rules and/or policies, hasbeen accepted. Acceptance can be by either entity of the relationship,or by both entities. To the extent that there is mutual acceptance, aservice management infrastructure can be configured at 622, whereby therequested access to the service is implemented according to a behaviorimposed by the roles, rules and/or policies of the relationship. To theextent that there no indicia or record of mutual acceptance, variousprocessing can take place at 620, for example, denying access to therequested interaction, denying access to a modification of the requestedinteraction according to a behavior of a predetermined relationship, orboth. It is understood that an exchange of attributes between one ormore of the parties can occur, e.g., in a context of a request for theinteraction or in response to identification of a predetermined rule.

FIG. 6B depicts an illustrative embodiment of another process 650 thatcan be used by the relationship management systems of FIGS. 1-3 and 5.In particular, the process 650 relates to creating and/or modifying arule associated with a relationship that can be used to configure anetwork element to obtain reconfigured infrastructure that providesnetwork-accessible services according to the rule. The network elementcan include, without limitation, any device or system of devices,whether real and/or virtual, hardware and/or software that are connectedto, part of, or otherwise accessible via a communications network. Insome embodiments, one of the first entity, the second entity or both isa network service provider providing one of the service, e.g., anetwork-accessible service, the network element, the infrastructureequipment that supports access to the network element, or a combinationthereof. Such service providers can include, without limitation, networkservice providers, cloud service providers, content service providers,application service providers, and so on.

One or more selectable rules are presented to equipment of a first partyand a second party at 652. The selectable rules can be used to define arelationship between the parties. The selectable rules can be presentedas options or preferences to each of the parties. The parties can makeselections based on the presented options. The selections can be madeindependently or collectively, e.g., from a common or shared selectionscreen of a user interface. The selections can include rules that aredefined in whole or in part by one or both of the parties.

It is generally understood that a social relationship may exist betweenthe parties. The social relationship can be based on one or more ofsocietal status, occupation, association, location, preference, and soon. The social relationships can include behaviors, traits,characteristics, expectations, norms, and so on that apply tointeractions involving one or more of the parties to the relationship.

A rule is generated at 654 according to first selections received fromthe equipment of the first party and second selections received from theequipment of the second party. The rule, in defining the relationship,can define or otherwise characterize one or more of the behaviors,traits, characteristics, expectations, norms as they may apply to therelationship itself, and/or interactions of one or more of the partiesto the relationship with network-accessible services.

The first rule is associated with the relationship between the firstparty and the second party at 656. In some embodiments, the rule can bestored in association with the relationship at 658. The association canbe captured using any suitable data structure. In the illustrativeembodiments, a database is used to store associations of the rules withthe relationships between parties. For example, a database record caninclude identifiers for both parties, an identifier of the relationship,which can include a type identifier (e.g., according to a number ofstandard types of social relationships), and the first rule. The firstrule can be captured in the database record as an identifier and/orpointer to particulars of the first rule, a description of the firstrule, the actual rule, executable code, script, or file, etc. It isunderstood that the foregoing can be accomplished during a design and/orreconfiguration process or phase, e.g., during interactions with theservice configuration system 320 (FIG. 3).

A request to access the network-accessible service is received at 660.The request can be received from a communication device, such as a smartphone, tablet or server of one of the parties. Alternatively or inaddition, the request can be received from equipment of another partywho is associated with the relationship. Other parties who can beassociated with relationships can include, without limitation, proxies,e.g., a spouse or parent, delegates, associates, e.g., officers,managers and/or employees of a business entity. It is understood thatsuch associated parties can be defined and stored in association withthe relationship providing the associated parties with access tonetwork-accessible service in accordance with rules agreed to betweenthe first and second parties.

A determination is made at 662 as to whether the request is associatedwith the relationship. For example, a request can be associated with anaccess and/or authorization process to identify to a pre-establisheddegree of certainty that the requestor is associated with therelationship. This process can be as simple as obtaining a user IDand/or equipment ID in association with the request. In someembodiments, the requestor can be queried, tested, and so on. It is alsounderstood that such authentication, authorization and/or subscriptioncan be applied as a prerequisite for providing selectable rules 652 andgenerating the rule at 654 and associating the rule with therelationship at 656.

To the extent that it is not associated with the relationship, theprocess continues to receive requests to access service 660, determiningwhether each subsequent request is associated with the relationship at662. To the extent that the request is associated with the relationship,the first rule is retrieved at 664. For example, the rule can beretrieved and/or otherwise accessed by information stored with therelationship at 658.

The network element is configured at 666 based on the rule to obtain areconfigured infrastructure. In some embodiments, the configuration isestablished once, e.g., in association with generation of the first ruleat 654 and association of the first rule with the relationship at 656.Alternatively or in addition, the configuration can be established inassociation with the request for access at 660 and confirmation that therequest is associated with the relationship at 662. It is conceivablethat a portion of the configuration can be established during generationof the rule, and another portion of the configuration being establishedin response to access requests. Access to the network-accessible serviceis provided via the reconfigured infrastructure equipment at 668.

FIG. 7 depicts an illustrative embodiment of another process 700 used bythe relationship management systems of FIGS. 1-3 and 5. In particular,the process 700 relates to creating and/or modifying a predeterminedrelationship that can be used to modify a behavior of an electronic ordigital interaction of one or more parties. A request to add and/ormodify a role, rule and/or policy of a relationship between two entitiesis received at 702. In some embodiments, separate actions are undertakento control access to relationship features. For example, according tothe illustrative embodiments, one or both of the entities can beauthenticated at 704. Alternatively or in addition, one or both of theentities can be authorized at 706, ensuring that only authenticated andauthorized entities can participate in creation and/or modification ofrelationships.

A determination is made at 708 as to whether a relationship alreadyexists between the entities. This may occur when the entities areupdating or otherwise modifying a predetermined relationship. To theextent that a relationship does exist, one or more parameters of therelationship, e.g., any roles, rules and/or policies associated with thepredetermined relationship are determined at 716. For example, theexisting parameters can be presented to one or both entities to supportor otherwise facilitate modification of an existing predeterminedrelationship.

To the extent that a relationship does not already exist, a relationshiptype can be identified at 710. In some instances, the relationship typecan be a name, tag or other suitable means for identifying therelationship. In such instances, the relationship can be named orotherwise identified according to the whims or wishes of the entities.Alternatively or in addition, the type of relationship may impart somesignificance to the relationship itself.

In some instances, default relationships are available, e.g., based onthe identified relationship type determined at 710. To the extent thereis a default relationship, the roles, rules and/or policies associatedwith the relationship are identified at 712. Any existing parametersrelated to the default relationship can be presented to one or bothentities to support or otherwise facilitate modification of an existingpredetermined relationship. One or both entities can add or modifyexisting roles, rules and/or policies at 714.

The relationship as created and/or modified is presented to both partiesfor review and approval. A determination is made at 718 as to whetherboth parties approved the new/modified relationship. To the extent thatthe relationship has been mutually approved, the relationship is updatedat 720 based on the defaults as well as any added and/or modified roles,rules and/or policies. The updated relationship can be stored orotherwise recorded at 722.

To the extent that the relationship has not been mutually approved at718, the entities can be presented with an option to revise the rule.This might occur under a negotiation of a relationship between the twoentities. An initial relationship can be approved and proposed by oneentity and submitted to the other entity for review and approval. Adetermination is made at 722 as to whether the relationship should berevised. To the extent that a revision is preferred, added and/ormodifications to the relationship are received at 714. Processingcontinues from 714 as set forth above. To the extent that a revision isnot preferred, the proposed relationship can be rejected at 724.

FIG. 8 depicts an illustrative embodiment of yet another process 800used by the relationship management systems of FIGS. 1-3 and 5. Inparticular, the process 800 relates to requesting creation of a newrelationship or modification of predetermined relationship that modifiesa behavior of an electronic or digital interaction of one or moreparties. A request create and/or modify a relationship with anotherentity is provided at 802. In some embodiments, separate actions areundertaken to control access to relationship features. For example,according to the illustrative embodiments a requesting party providesauthentication at 804. In some embodiments, authorization can also berequested from the other party at 804.

A determination is made at 806 as to whether the requested relationshipis an existing relationship. To the extent the requested relationship isan existing one, a determination of the roles, rules and/or policies ofthe relationship can be determined at 808. To the extent that therequested relationship is not an existing one, a selection can be madeat 812 of a predefined relationship. Such a selection may be from a menuor listing of available relationships. In either event, additions and/ormodifications of the relationship roles, rules and/or policies areprovided at 814.

A determination is made at 816 as to whether both parties assented to orotherwise agreed to the new/modified relationship. To the extent thatthe relationship has been mutually approved, a request can be made forstoring the new and/or modified relationship at 818. It is understoodthat in some instances, a specific request to store the relationship maynot be necessary, the relationship being stored automatically, e.g., inresponse to mutual assent at 816. To the extent it is determined at 816that the relationship has not been mutually assented to; the requestingentity can follow up with the other entity at 820. Such follow up can beformalized, e.g., according to a predetermined protocol, or informal,e.g., by way of a message exchange and/or voice call or meeting.Depending upon the results of such a follow up, the process may returnto providing added and/or modified rules at 814, followed by asubsequent determination whether mutual assent to the modifiedrelationship is obtained at 816.

The roles, rules and/or policies generally describe behaviors applied toelectronic or digital interactions. The behaviors may be implemented bya service provider (data access, functionality of app., message/calltransfer, etc.) based rules that may also rely on one or more attributes(fixed and/or dynamic). By way of example, reachability of one party byanother may depend on a dynamic attribute, such as a date, time of day,a schedule, an event, and/or equipment. Consider a lawyer, Jane, who hasestablished a predetermined relationship with an important client thatallows the client to reach Jane by voice at any day or time of day,unless Jane's schedule and location both indicate that she is in court.Other rules to the same relationship may vary a mode of an interaction,e.g., providing a call alternative, again based on one or more of adate, location, and so forth.

In another example, a customer accesses services, such as mediaservices, of a media content service provider. The customer and theservice provider have established a predetermined relationship in whichthe customer can access content from certain approved devices, e.g., thecustomer's home entertainment system. According to rules of thepredetermined relationship, charges and/or rates may apply based onparticular Equipment IDs, locations and so forth. In this example, thecustomer's request for access to content provides an equipment IDattribute. This attribute is compared to a list of allowable equipmentIDs. Services are provided, modified and/or blocked based on attributesincluding the equipment ID according to the predetermined rules.

In another example employee's request to access a business system, e.g.,stored data and/or a server, or virtual machine, may be granted orotherwise restricted according to a predefined relationship between theemployee and the employer and/or between the employee and the virtualmachine as an entity. Consider situations in which the employee may beable to access the virtual machine based on one or more of time of day,employee location, device used by employee. Such restrictions can beused as an added measure of flexibility and security, ensuring that theemployee cannot access sensitive information in unauthorized locations,such as coffee shops or restaurants.

In yet another example, access to patient records and/or a medicalapplication related to the patient records is managed according to oneor more predetermined relationships between the patient and otherentities. In a first relationship, a doctor-patient relationship, thepatient establishes a relationship with a primary care physician, Doc.A. Establishing the relationship may be according to a request from oneof the parties, e.g., the patient, that include an identified rule. Forexample, the rule can allow Doc. A to read and write medical informationinto online medical records of the patient according to anetwork-accessible medical records management system. Doc. A may acceptthe proposed rule of the doctor-patient relationship as stated by thepatient. Alternatively, Doc. A may counter with a modified and or newrule(s), seeking acceptance by the patient of the modified rules. Thepatent may accept, reject and/or further modify the rule(s) as desired.The process can continue until the parties reach a mutual accent orterminate the negotiations.

It is conceivable that in some relationships, one of the parties may beunwilling to negotiate, per se, rather providing a rule or set of rulesfor a given relationship as a “take it or leave it” proposition.Consider the doctor-patient relationship in which Doc. A may offer aspecific rule or set of rules to the patient. If the patient assents,then the relationship is established. Otherwise the relationship is notestablished.

The relationship may allow Doc. A to read and write to various fieldswithin the patients' medical records. In a second relationship, alsodoctor-patient relationship, the patient establishes a relationship witha specialist, Doc. B. The relationship may allow Doc. B to read, but notwrite to various fields within the patients' same medical records. Therelationships, once established and mutually agree do, can beimplemented during subsequent interactions with the patient's medicalrecords, such that Doc. B can access the latest, up-to-date informationabout the patient, without having to make separate requests and/orobtain authorization for each instance.

In more detail, a service provider, such as a network service provideroffers the medical records application as a service. The network serviceprovider may also manage the relationships, such that pre-definedrelationships between parties are stored and accessible to the networkservice provider. When a party makes a request through the network foran interaction with the patient's medical records, the network serviceprovider detects the requested interaction and determines whether arelationship exists. This may be a multi-step process in which theparties are first identified, e.g., patient and Doc. A. A relationshipdatabase can store records retaining predefined relationships betweenthe patient and Doc. A.

In some instances, the request for services is further examined todetermine if the relationship is within scope. For example, if therequest is to access the medical records application, and the behaviorcontrolling access to medical records is identified by the rules of therelationship, then the request can be considered in scope and theparticular behavior of the relationship applied to the request, e.g.,allowing Doc. A to read from and/or write to the medical records of thepatient. Access may be further restricted based on Doc. A's location,e.g., only allowing access when Doc. A is at the hospital. If, howeverthe request from Doc. A is a solicitation, e.g., for new conciergeservices, the interaction may be outside the scope of the relationshipand blocked or otherwise handled according to default call/messagerouting rules.

It is also understood that one or more of the communications, theresource subjected to the requested interaction and/or the relationshipmanager can be controlled or otherwise managed by the same entity, e.g.,the network services provider. Alternatively, one or more of thecommunications, the resource subjected to the requested interactionand/or the relationship manager can be implemented by differententities. When managed by different entities, further agreements and/orarrangements may be required to ensure that rules and/or policies of abehavior associated with a relationship will be implemented.

By way of further illustration, consider the doctor-patient example, inwhich one entity provides the managed medical records application, whileanother entity provides communications supporting remote access of theapplication. The communications entity can monitor communications forrequest to interaction with the application, forwarding such request tothe application service provider for processing according to a behaviorof the relationship. The relationship manager can be provided by eitherof the above entities, or by an entirely different entity offeringrelationship management services. In the latter scenario, agreementsbetween the relationship service provider to one or more of the otherentities can be established to allow for information sharing, access,accounting, and/or billing as may be related to the processing ofelectronic interactions according to the managed relationships.

FIG. 9 depicts an illustrative embodiment of a first communicationsystem 900 for delivering media content. The communication system 900can represent an Internet Protocol Television (IPTV) media system.Communication system 900 can be overlaid or operably coupled with thesystems of FIGS. 1-3 and 5 as another representative embodiment ofcommunication system 900. For instance, one or more devices illustratedin the communication system 900 of FIG. 9 can be configured to determinea request for an electronic interaction associated with a first partyand a second party. A relationship between the first party and thesecond party can be identified, wherein the relationship includes apredetermined rule that affects a behavior of the electronicinteraction. An acceptance of the rule by each of the first party andthe second party is confirmed and, subject to confirmation, the rule isapplied to the electronic interaction to affect the behavior of theelectronic interaction.

The IPTV media system can include a super head-end office (SHO) 910 withat least one super headend office server (SHS) 911 which receives mediacontent from satellite and/or terrestrial communication systems. In thepresent context, media content can represent, for example, audiocontent, moving image content such as 2D or 3D videos, video games,virtual reality content, still image content, and combinations thereof.The SHS server 911 can forward packets associated with the media contentto one or more video head-end servers (VHS) 914 via a network of videohead-end offices (VHO) 912 according to a multicast communicationprotocol.

The VHS 914 can distribute multimedia broadcast content via an accessnetwork 918 to commercial and/or residential buildings 902 housing agateway 904 (such as a residential or commercial gateway). The accessnetwork 918 can represent a group of digital subscriber line accessmultiplexers (DSLAMs) located in a central office or a service areainterface that provide broadband services over fiber optical links orcopper twisted pairs 919 to buildings 902. The gateway 904 can usecommunication technology to distribute broadcast signals to mediaprocessors 906 such as Set-Top Boxes (STBs) which in turn presentbroadcast channels to media devices 908 such as computers or televisionsets managed in some instances by a media controller 907 (such as aninfrared or RF remote controller).

The gateway 904, the media processors 906, and media devices 908 canutilize tethered communication technologies (such as coaxial, powerlineor phone line wiring) or can operate over a wireless access protocolsuch as Wireless Fidelity (WiFi), Bluetooth®, Zigbee®, or other presentor next generation local or personal area wireless network technologies.By way of these interfaces, unicast communications can also be invokedbetween the media processors 906 and subsystems of the IPTV media systemfor services such as video-on-demand (VoD), browsing an electronicprogramming guide (EPG), or other infrastructure services.

A satellite broadcast television system 929 can be used in the mediasystem of FIG. 9. The satellite broadcast television system can beoverlaid, operably coupled with, or replace the IPTV system as anotherrepresentative embodiment of communication system 900. In thisembodiment, signals transmitted by a satellite 915 that include mediacontent can be received by a satellite dish receiver 931 coupled to thebuilding 902. Modulated signals received by the satellite dish receiver931 can be transferred to the media processors 906 for demodulating,decoding, encoding, and/or distributing broadcast channels to the mediadevices 908. The media processors 906 can be equipped with a broadbandport to an Internet Service Provider (ISP) network 932 to enableinteractive services such as VoD and EPG as described above.

In yet another embodiment, an analog or digital cable broadcastdistribution system such as cable TV system 933 can be overlaid,operably coupled with, or replace the IPTV system and/or the satelliteTV system as another representative embodiment of communication system900. In this embodiment, the cable TV system 933 can also provideInternet, telephony, and interactive media services. System 900 enablesvarious types of interactive television and/or services including IPTV,cable and/or satellite.

The subject disclosure can apply to other present or next generationover-the-air and/or landline media content services system.

Some of the network elements of the IPTV media system can be coupled toone or more computing devices 930, a portion of which can operate as aweb server for providing web portal services over the ISP network 932 towireline media devices 908 or wireless communication devices 916.

Communication system 900 can also provide for all or a portion of thecomputing devices 930 to function as a relationship server orrelationship manager (herein referred to as relationship manager 930).The relationship manager 930 can use computing and communicationtechnology to perform function 962, which can include among otherthings, the relationship management techniques described by processes600 of FIG. 6A, process 650 of FIG. 6B and process 700 of FIG. 7. Forinstance, function 962 of server 930 can be similar to the functionsdescribed for the modules 104, 204, 312, 508 or sub-modules of FIGS. 1-3and 5, in accordance with the processes 600, 650, 700, 800 of FIGS. 6A,6B and 7-8. The media processors 906 and wireless communication devices916 can be provisioned with software functions 964 and 966,respectively, to utilize the services of relationship manager 930. Forinstance, functions 964 and 966 of media processors 906 and wirelesscommunication devices 916 can be similar to the functions described forthe modules 104, 204, 312, 508 or sub-modules of FIGS. 1-3 and 5, inaccordance with the processes 600, 650, 700, 800 of FIGS. 6A, 6B and7-8.

Multiple forms of media services can be offered to media devices overlandline technologies such as those described above. Additionally, mediaservices can be offered to media devices by way of a wireless accessbase station 917 operating according to common wireless access protocolssuch as Global System for Mobile or GSM, Code Division Multiple Accessor CDMA, Time Division Multiple Access or TDMA, Universal MobileTelecommunications or UMTS, World interoperability for Microwave orWiMAX, Software Defined Radio or SDR, Long Term Evolution or LTE, and soon. Other present and next generation wide area wireless access networktechnologies can be used in one or more embodiments of the subjectdisclosure.

FIG. 10 depicts an illustrative embodiment of a web portal 1002 of acommunication system 1000. Communication system 1000 can be overlaid oroperably coupled with the relationship management systems 100, 200, 300and 500 of FIGS. 1-3 and/or 5, communication system 900, and/orcommunication system 900 as another representative embodiment ofrelationship management systems 100, 200, 300 and 500 of FIGS. 1-3and/or 5, communication system 900, and/or communication system 900. Theweb portal 1002 can be used for managing services of relationshipmanagement systems 100, 200, 300 and 500 of FIGS. 1-3 and/or 5 andcommunication systems 900. A web page of the web portal 1002 can beaccessed by a Uniform Resource Locator (URL) with an Internet browserusing an Internet-capable communication device such as those describedFIGS. 1-3 and 5. The web portal 1002 can be configured, for example, toaccess a media processor 906 and services managed thereby such as aDigital Video Recorder (DVR), a Video on Demand (VoD) catalog, anElectronic Programming Guide (EPG), or a personal catalog (such aspersonal videos, pictures, audio recordings, etc.) stored at the mediaprocessor 906. The web portal 1002 can also be used for provisioning IMSservices described earlier, provisioning Internet services, provisioningcellular phone services, and so on.

The web portal 1002 can further be utilized to manage and provisionrelationship management software applications 962-966 to adapt theseapplications as may be desired by subscribers and/or service providersof relationship management systems 100, 200, 300 and 500 of FIGS. 1-3and/or 5, and communication system 900. For instance, users of theservices provided by any of the modules 104, 204, 312, 508 orsub-modules and/or the server 930 can log into their on-line accountsand provision the servers modules 104, 204, 312, 508 or sub-modules orserver 930 to create, modify or otherwise manage user profiles,subscriber accounts, managed relationships, and access to resourcesand/or services to enable it to communication with devices described inFIGS. 1-3, 5 and 9, and so on. Service providers can log onto anadministrator account to provision, monitor and/or maintain therelationship management systems 100, 200, 300 and 500 of FIGS. 1-3and/or 5, or server 930.

FIG. 11 depicts an illustrative embodiment of a communication device1100. Communication device 1100 can serve in whole or in part as anillustrative embodiment of the devices depicted in FIGS. 1-3 and/or 5,and FIG. 9 and can be configured to perform portions of the relationshipmanagement processes of 600, 650 700, 800 of FIGS. 6A, 6B and 7-8.

Communication device 1100 can comprise a wireline and/or wirelesstransceiver 1102 (herein transceiver 1102), a user interface (UI) 1104,a power supply 1114, a location receiver 1116, a motion sensor 1118, anorientation sensor 1120, and a controller 1106 for managing operationsthereof. The transceiver 1102 can support short-range or long-rangewireless access technologies such as Bluetooth®, ZigBee®, WiFi, DECT, orcellular communication technologies, just to mention a few (Bluetooth®and ZigBee® are trademarks registered by the Bluetooth® Special InterestGroup and the ZigBee® Alliance, respectively). Cellular technologies caninclude, for example, CDMA-1X, UMTS/HSDPA, GSM/GPRS, TDMA/EDGE, EV/DO,WiMAX, SDR, LTE, as well as other next generation wireless communicationtechnologies as they arise. The transceiver 1102 can also be adapted tosupport circuit-switched wireline access technologies (such as PSTN),packet-switched wireline access technologies (such as TCP/IP, VoIP,etc.), and combinations thereof.

The UI 1104 can include a depressible or touch-sensitive keypad 1108with a navigation mechanism such as a roller ball, a joystick, a mouse,or a navigation disk for manipulating operations of the communicationdevice 1100. The keypad 1108 can be an integral part of a housingassembly of the communication device 1100 or an independent deviceoperably coupled thereto by a tethered wireline interface (such as a USBcable) or a wireless interface supporting for example Bluetooth®. Thekeypad 1108 can represent a numeric keypad commonly used by phones,and/or a QWERTY keypad with alphanumeric keys. The UI 1104 can furtherinclude a display 1110 such as monochrome or color LCD (Liquid CrystalDisplay), OLED (Organic Light Emitting Diode) or other suitable displaytechnology for conveying images to an end user of the communicationdevice 1100. In an embodiment where the display 1110 is touch-sensitive,a portion or all of the keypad 1108 can be presented by way of thedisplay 1110 with navigation features.

The display 1110 can use touch screen technology to also serve as a userinterface for detecting user input. As a touch screen display, thecommunication device 1100 can be adapted to present a user interfacewith graphical user interface (GUI) elements that can be selected by auser with a touch of a finger. The touch screen display 1110 can beequipped with capacitive, resistive or other forms of sensing technologyto detect how much surface area of a user's finger has been placed on aportion of the touch screen display. This sensing information can beused to control the manipulation of the GUI elements or other functionsof the user interface. The display 1110 can be an integral part of thehousing assembly of the communication device 1100 or an independentdevice communicatively coupled thereto by a tethered wireline interface(such as a cable) or a wireless interface.

The UI 1104 can also include an audio system 1112 that utilizes audiotechnology for conveying low volume audio (such as audio heard inproximity of a human ear) and high volume audio (such as speakerphonefor hands free operation). The audio system 1112 can further include amicrophone for receiving audible signals of an end user. The audiosystem 1112 can also be used for voice recognition applications. The UI1104 can further include an image sensor 1113 such as a charged coupleddevice (CCD) camera for capturing still or moving images.

The power supply 1114 can utilize common power management technologiessuch as replaceable and rechargeable batteries, supply regulationtechnologies, and/or charging system technologies for supplying energyto the components of the communication device 1100 to facilitatelong-range or short-range portable applications. Alternatively, or incombination, the charging system can utilize external power sources suchas DC power supplied over a physical interface such as a USB port orother suitable tethering technologies.

The location receiver 1116 can utilize location technology such as aglobal positioning system (GPS) receiver capable of assisted GPS foridentifying a location of the communication device 1100 based on signalsgenerated by a constellation of GPS satellites, which can be used forfacilitating location services such as navigation. The motion sensor1118 can utilize motion sensing technology such as an accelerometer, agyroscope, or other suitable motion sensing technology to detect motionof the communication device 1100 in three-dimensional space. Theorientation sensor 1120 can utilize orientation sensing technology suchas a magnetometer to detect the orientation of the communication device1100 (north, south, west, and east, as well as combined orientations indegrees, minutes, or other suitable orientation metrics).

The communication device 1100 can use the transceiver 1102 to alsodetermine a proximity to a cellular, WiFi, Bluetooth®, or other wirelessaccess points by sensing techniques such as utilizing a received signalstrength indicator (RSSI) and/or signal time of arrival (TOA) or time offlight (TOF) measurements. The controller 1106 can utilize computingtechnologies such as a microprocessor, a digital signal processor (DSP),programmable gate arrays, application specific integrated circuits,and/or a video processor with associated storage memory such as Flash,ROM, RAM, SRAM, DRAM or other storage technologies for executingcomputer instructions, controlling, and processing data supplied by theaforementioned components of the communication device 1100.

Other components not shown in FIG. 11 can be used in one or moreembodiments of the subject disclosure. For instance, the communicationdevice 1100 can include a reset button (not shown). The reset button canbe used to reset the controller 1106 of the communication device 1100.In yet another embodiment, the communication device 1100 can alsoinclude a factory default setting button positioned, for example, belowa small hole in a housing assembly of the communication device 1100 toforce the communication device 1100 to re-establish factory settings. Inthis embodiment, a user can use a protruding object such as a pen orpaper clip tip to reach into the hole and depress the default settingbutton. The communication device 1100 can also include a slot for addingor removing an identity module such as a Subscriber Identity Module(SIM) card. SIM cards can be used for identifying subscriber services,executing programs, storing subscriber data, and so forth.

The communication device 1100 as described herein can operate with moreor less of the circuit components shown in FIG. 11. These variantembodiments can be used in one or more embodiments of the subjectdisclosure.

The communication device 1100 can be adapted to perform the functions ofthe equipment of the entities 102, the relationship manager 104, and orequipment supporting one or more of the storage, application, processingand/or network services 110 of FIG. 1. Likewise, the communicationdevice 1100 can be adapted to perform one or more of the functions ofthe equipment of the equipment, e.g., 202, 204, 206, 210 of FIG. 2, theequipment, e.g., 302, 304, 306, 312, 316 of FIG. 3, and equipmentsupporting the system 500 of FIG. 5. Devices of FIGS. 1-3 and/or 5, themedia processor 906, the media devices 908, or the portablecommunication devices 916 of FIG. 9. It will be appreciated that thecommunication device 1100 can also represent other devices that canoperate in FIGS. 1-3 and/or 5, communication system 900 of FIG. 4 suchas a gaming console and a media player. In addition, the controller 1106can be adapted in various embodiments to perform the relationshipmanagement functions 962-966.

The environments disclosed herein allow each party to create multiplebehavior capabilities that render specific, subscribed client behaviors.Such capabilities can be managed by leveraging common tool sets, e.g.,available from a service provider. Thus, one party can have subscribedbehaviors unique to itself every other potential client connection.Alternatively or in addition, the party can have “aggregated” behaviorsfor specific groups of clients. Where there is some adaptation to arelationship between different parties, the relationship can be definedseparately for any specific request for interactions associated with theparties. This invention allows the relationship to be defined separatelyfrom any request. The relationship can remain in effect regardless ofthe request.

Upon reviewing the aforementioned embodiments, it would be evident to anartisan with ordinary skill in the art that said embodiments can bemodified, reduced, or enhanced without departing from the scope of theclaims described below. For example, rules/behaviors and/or control canbe aggregated among entities or personas (e.g., applied to multiplemembers of a business group entity, a family entity, a social group, anaffinity group). Consider a baseline rule that is published or otherwisedelivered to members of a group. In some embodiments, the individualgroup members may simply accept or reject the baseline rule. In otherinstances, the individual group members may undertake a tailoring and orpersonalizing of baseline rule. Such modifications can be performed byselectable or otherwise choosing among a number of predefined variableparameters.

In some embodiments, personas and/or relationships can be included in aconfiguration file, such as a user and/or system profile or description.It is conceivable that one or more of personas, relationship types, orroles, rules and policies as they relate to behavior of interactions canbe captured in software, e.g., software libraries, firmware, or evenhardware, e.g., SIM cards, for reuse, sale or lease.

The techniques disclosed herein can supports an entity with managedaccess to data, network, and/or computing resources across one ormultiple devices individually or simultaneously. That is, a user underthe same managed relationship may engage in interactions on a firstdevice, such as a media player presenting interactive media content,while engaging in interactions on a second device, such as a computerand/or smart phone. The phone can be used for a side channel, e.g., in acomputer gaming scenario in which members of a team engage in gameplaywith other teams as presented through the media player and/or gameconsole.

Management of interactions based on pre-defined relationships cansupport various billing and accounting scenarios. For example, chargesfor services can be established based on a particular relationship. Asthe relationship may evolve over time, and/or based on occurrences ofcertain events, so to may billing and/or accounting. Such evolution ofthe relationship can be accounted for during a definition and mutualassent of the relationship. Accordingly, the behavior imposed by thepredefined relationship may vary depending upon a state of therelationship as determined by an occurrence or non-occurrence of aparticular event, or so forth. In some embodiments, the mutually agreedto relationship can terminate based on an occurrence or non-occurrenceof a particular event, or so forth.

It is also understood that in at least some instances, ratificationand/or termination of a predefined relationship can be accomplishedunilaterally. That is, one or both parties may have a right to cancel arelationship at any time, without requiring assent of the other party.Likewise, assent to the original pre-defined relationship may allow oneor both of the parties to unilaterally ratify the relationship byaltering, adding and/or removing certain predefined roles, rules and/orpolicies.

It is also understood that the techniques disclosed herein can support afocused use-based billing, e.g., charges can be tied to entity and notto underlying device. By way of example, a student, Claire, places acall, and/or accesses data using a fellow student's, Dan's, devicesmartphone or tablet device. Claire authenticates herself and/or one ofhere personas, e.g., as illustrated in FIG. 2, to participate in aninteraction subject to one of her predefined relationships. Acommunication service provider recognizing Clair's relationship providesservices as required by the interaction. The service provider canaccount for data usage, calls, etc., under Claire's account, withoutaccruing any overlapping charges to Dan's account, even though theservices were delivered using Dan's device.

In general, an identifier function can be launched, e.g., providingend-to-end behavior, based on authentication and/or authorization, userrole and attributes, device characteristics, subscribed behavior and soforth as covered by the predetermined relationship. Other embodimentscan be used in the subject disclosure.

It should be understood that devices described in the exemplaryembodiments can be in communication with each other via various wirelessand/or wired methodologies. The methodologies can be links that aredescribed as coupled, connected and so forth, which can includeunidirectional and/or bidirectional communication over wireless pathsand/or wired paths that utilize one or more of various protocols ormethodologies, where the coupling and/or connection can be direct (e.g.,no intervening processing device) and/or indirect (e.g., an intermediaryprocessing device such as a router).

FIG. 12 depicts an exemplary diagrammatic representation of a machine inthe form of a computer system 1200 within which a set of instructions,when executed, may cause the machine to perform any one or more of themethods described above. One or more instances of the machine 1200 canoperate as any of the modules, engines and servers disclosed herein. Forexample, the machine 1200 can operate as the relationship manager 104,204 of FIGS. 1-2, the service information module 312 and/or the productinformation module 306 of FIG. 3, or the customer experience rulesmodule 508 of FIG. 5, or the server 930, the media processor 906. Insome embodiments, the machine may be connected (e.g., using a network1226) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client user machine in aserver-client user network environment, or as a peer machine in apeer-to-peer (or distributed) network environment.

The machine may comprise a server computer, a client user computer, apersonal computer (PC), a tablet, a smart phone, a laptop computer, adesktop computer, a control system, a network router, switch or bridge,or any machine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. It will beunderstood that a communication device of the subject disclosureincludes broadly any electronic device that provides voice, video ordata communication. Further, while a single machine is illustrated, theterm “machine” shall also be taken to include any collection of machinesthat individually or jointly execute a set (or multiple sets) ofinstructions to perform any one or more of the methods discussed herein.

The computer system 1200 may include a processor (or controller) 1202(e.g., a central processing unit (CPU)), a graphics processing unit(GPU, or both), a main memory 1204 and a static memory 1206, whichcommunicate with each other via a bus 1208. The computer system 1200 mayfurther include a display unit 1210 (e.g., a liquid crystal display(LCD), a flat panel, or a solid state display). The computer system 1200may include an input device 1212 (e.g., a keyboard), a cursor controldevice 1214 (e.g., a mouse), a disk drive unit 1216, a signal generationdevice 1218 (e.g., a speaker or remote control) and a network interfacedevice 1220. In distributed environments, the embodiments described inthe subject disclosure can be adapted to utilize multiple display units1210 controlled by two or more computer systems 1200. In thisconfiguration, presentations described by the subject disclosure may inpart be shown in a first of the display units 1210, while the remainingportion is presented in a second of the display units 1210.

The disk drive unit 1216 may include a tangible computer-readablestorage medium 1222 on which is stored one or more sets of instructions(e.g., software 1224) embodying any one or more of the methods orfunctions described herein, including those methods illustrated above.The instructions 1224 may also reside, completely or at least partially,within the main memory 1204, the static memory 1206, and/or within theprocessor 1202 during execution thereof by the computer system 1200. Themain memory 1204 and the processor 1202 also may constitute tangiblecomputer-readable storage media.

Dedicated hardware implementations including, but not limited to,application specific integrated circuits, programmable logic arrays andother hardware devices can likewise be constructed to implement themethods described herein. Application specific integrated circuits andprogrammable logic array can use downloadable instructions for executingstate machines and/or circuit configurations to implement embodiments ofthe subject disclosure. Applications that may include the apparatus andsystems of various embodiments broadly include a variety of electronicand computer systems. Some embodiments implement functions in two ormore specific interconnected hardware modules or devices with relatedcontrol and data signals communicated between and through the modules,or as portions of an application-specific integrated circuit. Thus, theexample system is applicable to software, firmware, and hardwareimplementations.

In accordance with various embodiments of the subject disclosure, theoperations or methods described herein are intended for operation assoftware programs or instructions running on or executed by a computerprocessor or other computing device, and which may include other formsof instructions manifested as a state machine implemented with logiccomponents in an application specific integrated circuit or fieldprogrammable gate array. Furthermore, software implementations (e.g.,software programs, instructions, etc.) including, but not limited to,distributed processing or component/object distributed processing,parallel processing, or virtual machine processing can also beconstructed to implement the methods described herein. It is furthernoted that a computing device such as a processor, a controller, a statemachine or other suitable device for executing instructions to performoperations or methods may perform such operations directly or indirectlyby way of one or more intermediate devices directed by the computingdevice.

While the tangible computer-readable storage medium 1222 is shown in anexample embodiment to be a single medium, the term “tangiblecomputer-readable storage medium” should be taken to include a singlemedium or multiple media (e.g., a centralized or distributed database,and/or associated caches and servers) that store the one or more sets ofinstructions. The term “tangible computer-readable storage medium” shallalso be taken to include any non-transitory medium that is capable ofstoring or encoding a set of instructions for execution by the machineand that cause the machine to perform any one or more of the methods ofthe subject disclosure. The term “non-transitory” as in a non-transitorycomputer-readable storage includes without limitation memories, drives,devices and anything tangible but not a signal per se.

The term “tangible computer-readable storage medium” shall accordinglybe taken to include, but not be limited to: solid-state memories such asa memory card or other package that houses one or more read-only(non-volatile) memories, random access memories, or other re-writable(volatile) memories, a magneto-optical or optical medium such as a diskor tape, or other tangible media which can be used to store information.Accordingly, the disclosure is considered to include any one or more ofa tangible computer-readable storage medium, as listed herein andincluding art-recognized equivalents and successor media, in which thesoftware implementations herein are stored.

Although the present specification describes components and functionsimplemented in the embodiments with reference to particular standardsand protocols, the disclosure is not limited to such standards andprotocols. Each of the standards for Internet and other packet switchednetwork transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) representexamples of the state of the art. Such standards are from time-to-timesuperseded by faster or more efficient equivalents having essentiallythe same functions. Wireless standards for device detection (e.g.,RFID), short-range communications (e.g., Bluetooth®, WiFi, Zigbee®), andlong-range communications (e.g., WiMAX, GSM, CDMA, LTE) can be used bycomputer system 1200.

The illustrations of embodiments described herein are intended toprovide a general understanding of the structure of various embodiments,and they are not intended to serve as a complete description of all theelements and features of apparatus and systems that might make use ofthe structures described herein. Many other embodiments will be apparentto those of skill in the art upon reviewing the above description. Theexemplary embodiments can include combinations of features and/or stepsfrom multiple embodiments. Other embodiments may be utilized and derivedtherefrom, such that structural and logical substitutions and changesmay be made without departing from the scope of this disclosure. Figuresare also merely representational and may not be drawn to scale. Certainproportions thereof may be exaggerated, while others may be minimized.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

Although specific embodiments have been illustrated and describedherein, it should be appreciated that any arrangement which achieves thesame or similar purpose may be substituted for the embodiments describedor shown by the subject disclosure. The subject disclosure is intendedto cover any and all adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, can be used in the subject disclosure.For instance, one or more features from one or more embodiments can becombined with one or more features of one or more other embodiments. Inone or more embodiments, features that are positively recited can alsobe negatively recited and excluded from the embodiment with or withoutreplacement by another structural and/or functional feature. The stepsor functions described with respect to the embodiments of the subjectdisclosure can be performed in any order. The steps or functionsdescribed with respect to the embodiments of the subject disclosure canbe performed alone or in combination with other steps or functions ofthe subject disclosure, as well as from other embodiments or from othersteps that have not been described in the subject disclosure. Further,more than or less than all of the features described with respect to anembodiment can also be utilized.

Less than all of the steps or functions described with respect to theexemplary processes or methods can also be performed in one or more ofthe exemplary embodiments. Further, the use of numerical terms todescribe a device, component, step or function, such as first, second,third, and so forth, is not intended to describe an order or functionunless expressly stated so. The use of the terms first, second, thirdand so forth, is generally to distinguish between devices, components,steps or functions unless expressly stated otherwise. Additionally, oneor more devices or components described with respect to the exemplaryembodiments can facilitate one or more functions, where the facilitating(e.g., facilitating access or facilitating establishing a connection)can include less than every step needed to perform the function or caninclude all of the steps needed to perform the function.

In one or more embodiments, a processor (which can include a controlleror circuit) has been described that performs various functions. Itshould be understood that the processor can be multiple processors,which can include distributed processors or parallel processors in asingle machine or multiple machines. The processor can be used insupporting a virtual processing environment. The virtual processingenvironment may support one or more virtual machines representingcomputers, servers, or other computing devices. In such virtualmachines, components such as microprocessors and storage devices may bevirtualized or logically represented. The processor can include a statemachine, application specific integrated circuit, and/or programmablegate array including a Field PGA. In one or more embodiments, when aprocessor executes instructions to perform “operations”, this caninclude the processor performing the operations directly and/orfacilitating, directing, or cooperating with another device or componentto perform the operations.

The Abstract of the Disclosure is provided with the understanding thatit will not be used to interpret or limit the scope or meaning of theclaims. In addition, in the foregoing Detailed Description, it can beseen that various features are grouped together in a single embodimentfor the purpose of streamlining the disclosure. This method ofdisclosure is not to be interpreted as reflecting an intention that theclaimed embodiments require more features than are expressly recited ineach claim. Rather, as the following claims reflect, inventive subjectmatter lies in less than all features of a single disclosed embodiment.Thus the following claims are hereby incorporated into the DetailedDescription, with each claim standing on its own as a separately claimedsubject matter.

What is claimed is:
 1. A method, comprising: facilitating, by aprocessing system comprising a processor, a message from a firstcommunication device of a first party to a second communication deviceof a group of second communication devices of a second party;authenticating, by the processing system, the first communication devicebased on biometric data; responsive to the authenticating, determining,by the processing system, a first determined persona from a firstplurality of personas for the first party and a second determinedpersona from a second plurality of personas for the second party;generating, by the processing system, a first rule according to thefirst determined persona and the second determined persona, wherein thefirst rule defines an interaction between the first party and the secondparty; configuring, by the processing system, connectability by thefirst communication device to the group of second communication devicesaccording to the first rule; and providing, by the processing system, aconnection between the first communication device and one of the groupof second communication devices based on the configuring of theconnectability, based on the first rule, and based on a determination ofa present interaction between the first party and the second party. 2.The method of claim 1, wherein the biometric data comprises afingerprint, a retinal scan, a voice signature, a facial image, or acombination thereof.
 3. The method of claim 1, wherein theauthenticating comprises authenticating equipment of the first partybased on first biometric data of the first party and authenticatingequipment of the second party based on second biometric data of thesecond party.
 4. The method of claim 1, further comprising: determiningby the processing system, information concerning selection of selectablecharacteristics pertaining to a relationship between the first party andthe second party, wherein the configuring comprises configuring aninformation resource based on the first rule, resulting in a configuredservice system that supports access to the information resource vianetwork devices and equipment of the first party in accordance with thefirst rule and according to a determination that the equipment of thefirst party is authenticated, wherein the first rule comprisesinstructions to configure the network devices, executable code thatconfigures the network devices, or both.
 5. The method of claim 4,wherein the configuring is in response to receiving messages from theequipment of the first party and equipment of the second partyindicating an acceptance of the first rule.
 6. The method of claim 4,wherein the selectable characteristics comprise dynamic attributescomprising a location, a business group ID, a personal group ID, ahardware type, a hardware identifier, a date, a time, environmentalattributes, or a combination thereof.
 7. The method of claim 6, furthercomprising modifying, by the processing system, the first rule based onthe dynamic attributes.
 8. The method of claim 4, wherein the selectablecharacteristics comprise a behavior, a trait, an expectation, a norm, ora combination thereof of the relationship between the first party andthe second party.
 9. The method of claim 4, further comprising: storing,by the processing system, the first rule in association with therelationship between the first party and the second party; receiving, bythe processing system, a request to access the configured servicesystem; verifying, by the processing system, the first party, the secondparty, or both parties from the request to access the configured servicesystem based on the authenticating; identifying, by the processingsystem, the relationship based on identifying the first party, thesecond party, or both parties; and retrieving, by the processing system,the first rule in response to the identifying of the relationship. 10.The method of claim 4, further comprising: receiving, by the processingsystem, an update of the first rule; generating, by the processingsystem, a second rule based on the update; associating, by theprocessing system, the second rule with the relationship between thefirst party and the second party, wherein the second rule modifiessettings of the configured service system to effectuate the second rule;reconfiguring, by the processing system, the configured service systembased on the second rule resulting in a reconfigured service system thatsupports access to the information resource by the network devices inaccordance with the second rule; and providing, by the processingsystem, access to the information resource via the reconfigured servicesystem.
 11. The method of claim 10, further comprising: receiving, bythe processing system, a second request to access the informationresource; determining, by the processing system, that the second requestis associated with the relationship; and retrieving, by the processingsystem, the second rule in response to the determining that the secondrequest is associated with the relationship.
 12. The method of claim 1,wherein the authenticating comprises a dynamic authorization comprisinga multifactor identification of the first communication device.
 13. Themethod of claim 12, wherein the dynamic authorization further comprisesdetermining a contextual risk from equipment of one of the first partyand the second party.
 14. A device comprising: a processing systemincluding a processor; and a memory that stores executable instructionsthat, when executed by the processing system, facilitate performance ofoperations, comprising: facilitating a message from a firstcommunication device of a first party to a second communication deviceof a group of second communication devices of a second party;authenticating the first communication device based on biometric data;responsive to the authenticating, determining a first determined personafrom a first plurality of personas for the first party and a seconddetermined persona from a second plurality of personas for the secondparty; generating a first rule according to the first determined personaand the second determined persona, wherein the first rule defines aninteraction between the first party and the second party; configuringconnectability by the first communication device to the group of secondcommunication devices according to the first rule; and providing aconnection between the first communication device and one of the groupof second communication devices based on the configuring of theconnectability, based on the first rule, and based on a determination ofa present interaction between the first party and the second party, thepresent interaction pertaining to a social relationship between thefirst party and the second party.
 15. The device of claim 14, whereinthe biometric data comprises a fingerprint, a retinal scan, a voicesignature, a facial image, or a combination thereof.
 16. The device ofclaim 14, wherein the authenticating comprises authenticating equipmentof the first party based on first biometric data of the first party andauthenticating equipment of the second party based on second biometricdata of the second party.
 17. The device of claim 14, wherein theoperations further comprise: determining information concerningselection of selectable characteristics pertaining to the socialrelationship between the first party and the second party, wherein theconfiguring comprises configuring an information resource based on thefirst rule, resulting in a configured service system that supportsaccess to the information resource via network devices and equipment ofthe first party in accordance with the first rule and according to adetermination that the equipment of the first party is authenticated,wherein the first rule comprises instructions to configure the networkdevices, executable code that configures the network devices, or both,wherein the configuring is in response to receiving messages from theequipment of the first party and equipment of the second partyindicating an acceptance of the first rule.
 18. A machine-readablemedium comprising executable instructions that, when executed by aprocessing system including a processor, facilitate performance ofoperations, comprising: facilitating a message from a firstcommunication device of a first party to a second communication deviceof a group of second communication devices of a second party;authenticating the first communication device based on biometric data;responsive to the authenticating, determining a first determined personafrom a first plurality of personas for the first party and a seconddetermined persona from a second plurality of personas for the secondparty; generating a first rule according to the first determined personaand the second determined persona, wherein the first rule defines aninteraction between the first party and the second party; configuringconnectability by the first communication device to the group of secondcommunication devices according to the first rule; and providing aconnection between the first communication device and one of the groupof second communication devices based on the configuring of theconnectability, based on the first rule, and based on a determination ofa present interaction between the first party and the second party; anddetermining information concerning selection of selectablecharacteristics pertaining to a social relationship between the firstparty and the second party.
 19. The machine-readable medium of claim 18,wherein the biometric data comprises a fingerprint, a retinal scan, avoice signature, a facial image, or a combination thereof.
 20. Themachine-readable medium of claim 18, wherein the authenticatingcomprises authenticating equipment of the first party based on firstbiometric data of the first party and authenticating equipment of thesecond party based on second biometric data of the second party.